Currently there are challenges associated with efficiently and effectively developing larger and more complex products and systems for a wide variety of applications. More specifically, there is a need for a development methodology that would provide a standard for system design and specification throughout engineering teams including external organizations; allow for appropriate level of detail needed for defining a large complex system; and improve communications between engineering disciplines, particularly between systems engineers and software engineers.
Collective experience and research shows that there are a large number of existing alternatives for notations, development approaches and CASE tools available to support the development of large and complex systems. However, the available methods and tools only loosely imply a development approach instead of actually defining one.
Heretofore, in system design, functional decomposition was utilized to take a series of tasks and to provide a hierarchical structure so that the tasks could be broken down for further engineering. The problem in such a functional decomposition strategy is that if one has 4,000-5,000 tasks to do, one cannot easily manage the breakup of the system into an appropriate hierarchy.
Standard functional decomposition is a breakdown from the top level down to each individual lower level of the entire system design. Typically, one starts out with a system as one box and decomposes it into boxes that communicate with each other at lower and lower levels until one finally gets down to where decomposition is no longer useful. By taking the output of the decomposition, one can design those small components that have been decomposed.
If one wanted to use object-oriented techniques for complex system design, they would not be well adapted to a hierarchical structure since the object-oriented techniques all have the objects at the same level. Thus, object-oriented techniques were not generally utilized in complex system architecture or design.
The reason that object-oriented techniques do not operate at different levels is because there is a basic assumption in object-oriented programming which maintains that all objects have to communicate with each other. When they do, they must communicate with each other on the same level.
Object-oriented techniques are useful for very simplified system engineering and design tasks. But as the number of objects increases there is of necessity a need for objects to communicate with objects at various levels in a hierarchy. This is because it is the hierarchy that allows one to break down the tasks in a meaningful fashion. It is noted that many systems engineers who use a standard functional decomposition approach do so by generating PowerPoint presentations or utilize standard circuit design tools, all of which imply a hierarchical structure.
For functional decomposition, one writes down a document specification or other listing in which each element or each requirement that the system is expected to do is reflected in text. One then takes a look at these requirements and decomposes them into hardware and software requirements, at which point one hands off the hardware and software the requirements to hardware and software engineers to instruct them to build the system in accordance with those requirements.
The problem with such an approach is poor communication between the systems engineers and the electrical engineers, mechanical engineers and software engineers. In short, functional decomposition does not impose an overlying architecture that can guide the engineers.
The result of a lack of communication or the lack of each engineer knowing where his task lies within the hierarchy can result in glaring omissions. For instance, in designing a firefighting system in which one looks for forest fires and seeks to put them out, if one forgets to take into account that dropping water on an individual may cause injury or death and that the location of the individual must be accurately known when, for instance, a tanker drops flame retardant over a given area, then the omission is critical.
In complex systems it is highly desirable to minimize the omission type mistakes or misunderstandings that can flow from a pure functional decomposition approach to system design.